记住2个三连关键字，库存就一览无遗了。

事务类型

凡是存货的移动，对于财务来讲，都是需要记账，没商量。 1. 收货/发货 （存货资产账户和相关应收/应付过渡账户） 2. 调拨 (直接在存货资产账户借贷，如果内部往来，就在维度上设置平衡段) 3. 盘库、内部领用（盘库是库存差异账户，内部领用是成本费用账户或者使用杂费自己挂账户） 4. 项目投放（进WIP在产项目/在产品账户） 5. 简单生产（简单的仓库组装和拆解业务，直接借贷存货资产） 如果业务发生其他类型的存货移动，比如外协发货/收货、生产领料/退料，使用**万能**的第3项吧。 所有存货事务只要发生数量变化，肯定有一方是存货资产账户，另外一方是相应账户。如果只有一项对方账户，就用杂费开挂。如果有多项，但账户可以使用公式分摊，也可以先进一个杂费，再使用总账分配。如果多项无规律，就只能对此类单据二次开发做会计分录。 产品信息

库位三连

三连关键字：库位、产品属性、入库日期。 库位：M_Location，对应实际业务中的最小存储单元，对应财务的最小库存成本的统计单元。 产品属性：产品的非实例属性（颜色、尺寸）或者实例属性（批次、序列号、保质期），或者两者复合。 入库日期：DateMaterialPolicy，相当于“存货进入库位时间”

关于收发明细的属性分配的问题（各LineMa表）

如果是POS订单，故意取消属性集非必填，否则自动不不下，明细的MA行不会填入ASI数据，且为汇总数 如果是手工订单，在发货单明细下面可以手动分配MA，但是明细页签不自动汇总数量，额... **待测试MA**，总体目标：MA表要依据库存明细(m_storage)，自动或者手动分配给各发货明细。 1. 如果存货有多个产品属性，销售订单一行明细，要在发货明细下有多个产品属性的分配记录 2. 如果存货没有实例属性，销售订单一行明细，要在发货明细下游多个入库日期的分配（现在OK）

数量三连

三连关键字：在手数量、预留数量、在途数量 在手数量：QtyOnhand，实际库存数量，由m_storageonhand表的QtyOnhand字段存储。 预留/在途数量：QtyReserved，每个订单明细使用该字段，分别表示销售和采购的“在单数量”。当使用场景PO词条翻译时，在销售订单界面叫“预留数量”，在采购订单界面叫“在途数量”。最后更新到m_storagereservation表的一个字段Qty，但是会在m_storage分开，没毛病。 （跑龙套的第四个数量）订购数量：QtyOrdered，每个订单明细有这个搅屎棍字段，表示订单输入数量转换成库存单位后的订购数量，这个字段也要存在，没毛病。

确认二连

只有M_InOutLineConfirm，M_MovementLineConfirm 这2个表会卡住收发数量的移动。 再捋下所有库存事务的确认业务： 1. 收货/发货 （Confirm -> M_InOut，可选确认，有单独窗口，只要基础单据类型=收发单，就可使用确认） 2. 调拨 (Confirm -> M_Movement，内置必须确认，有单独的确认窗口 ) 3. 盘库、内部领用（【注意】没有确认功能，也就是盘库/内部领用，无需质检，单据完成即增减账面数量） 4. 项目投放（【注意】没有确认功能，也就是从库位投放物料到项目，无需质检，单据完成即增减账面数量） 5. 简单生产（【注意】没有确认功能，也就是物料组装或拆解生产，无需质检，单据完成即增减账面数量） 这就有点尴尬了，这么多出入库事务没有确认（质检）控制，客户肯定不让。 收发确认工作原理： 1. 单据未完成，草稿时创建确认单，确认前，原收发单据无法完成，状态=处理中。确认后，确认单会更新原单据的相应数量（有好几种确认，好几种数量）。原单据的所有确认完成后，才可以完成单据并更新库存。 2. 单据一旦完成，库存即更新。你也可以继续创建确认。确认数量还可以写回原单据，但是无法卡住移动数量。 不同确认类型分别写回不同的数量字段，对应关系如下： 确认数量：供应商/客户确认，可以理解为”采购收货“。 拣货数量：拣货/QC确认，可以理解为”品管拣货“。 目标数量：收发单确认，可以理解为”库管收货“。 对比还差什么，先去窗口直接找到确认按钮后面挂的什么： 1. 收发单 单据完成：如果未确认，单据无法完成，那MInOut.complete( )肯定包含了确认检查。如下代码。 创建确认：使用流程 org.compiere.process.InOutCreateConfirm 处理确认：使用”收发确认单“的单据处理流程 M_InOutConfirm_Process 挂单据处理工作流。 2. 调拨单（有点特殊） 创建确认：没有使用创建流程，由单据类型的”在途仓库“属性='Y'来创建确认。且完成确认，自动完成调拨单。 处理确认：使用”调拨确认单“的单据处理流程 M_MovementConfirm_Process 挂单据处理工作流 从上面2种确认的触发过程，可以得出增加其他单据确认的思路 1. 自动使用单据类型的在途仓库属性，但该属性仅用于单据基础类型=‘调拨单’（MMM），由MMovement.prepareIt ( )方法创建确认，其他单据都没有创建代码。且确认记录还是单独的调拨确认表，还不是常见的收发确认表。再且调拨单基本没有其他衍生单据。 2. 手动使用流程创建确认，仿照收发单，在单据完成前检查单据是否确认完成。 MInOut.java判断是否确认的代码

方法：completeIt( ) 
Line 1267 
//  Outstanding (not processed) Incoming Confirmations ?
    MInOutConfirm[] confirmations = getConfirmations(true);
    for (int i = 0; i < confirmations.length; i++)
    {
      MInOutConfirm confirm = confirmations[i];
      if (!confirm.isProcessed())
      {
        if (MInOutConfirm.CONFIRMTYPE_CustomerConfirmation.equals(confirm.getConfirmType()))
          continue;
        //
        m_processMsg = "Open @M_InOutConfirm_ID@: " +
          confirm.getConfirmTypeName() + " - " + confirm.getDocumentNo();
        return DocAction.STATUS_InProgress;
      }
    }

MMovement.java增加确认的代码

方法：prepareIt( )
L331
    //  Confirmation
    if (dt.isInTransit())                /* dt 表示单据类型 */
      createConfirmation();

m_storage

这是一个视图，2个表组成： （m_storageonhand + m_storagereservation在途 + m_storagereservation预留），当然你可以改写这个视图。 也就是“库位三连”+“数量三连”组成了m_storage的明细数据， 例子：某个库位的库存明细(m_storage) 产品 库位 产品属性 入库日期 在手数量 预留数量 在途数量 A L1 0 非实例 Date1 3 A L1 0 非实例 Date1 -2 A L1 0 非实例 Date1 10 A L1 0 非实例 Date2 10 B L1 Lot1 实例 Date1 10 B L1 Lot2 实例 Date1 10 1. 同一个库位的在手数量，不同入库日期分别计算，只统计到天。 2. **“产品属性=实例属性”**除外，即只要产品实例属性相同，不管入库日期，在手数量一并统计。 3. 在手数量、预留数量、在途数量都为0，，它不过滤，虽然也有点用。 4. 当然你还加入“未确认二连”数量。 加了入库日期字段

加了库位字段

表

==单据表头 c_order:订单（影响m_storagereservation表的预留、在途数据） m_inout:收货单、发货单（直接影响m_storageonhand） m_movement:调拨单（直接影响m_storageonhand） m_inventory:库存调整单（盘库、内部领用）（直接影响m_storageonhand） c_projectissue:项目投放单（直接影响m_storageonhand） m_m_production:生产工单（直接影响m_storageonhand） ==单据明细 与上面表头对应的明细和相应的产品属性分配（MA：Material Allocation） 表头Line：和上面一样 表头MA：和上面一样，待测试，老问题 ==库存表 m_storageonhand:在手库存 m_storagereservation:预留库存，就一个qty字段记录 ==事务日志 m_transaction:库存事务（5种库存事务的日志） m_transactionallocation：未用

报表

m_storage：库存 （m_storageonhand + m_storagereservation在途 + m_storagereservation预留） m_product_stock_v：产品库位信息 （m_storage + 仓库 + 库位） m_transaction_v：库存事务（m_transaction + 5种事务类型的收发明细） rv_storage：库存数量明细 （m_storage + 产品 + 属性 + 仓库 + 库位） rv_Transaction：收发事务明细 rv_m_transaction：收发事务明细（进价） rv_m_transaction_sum：收发事务明细（日报）

吐槽

==翻译qtyordered, qtyreserved 【毛病1开始了】 系统做了一个视图，把m_storageonhand和m_storagereservation合并起来，叫m_storage（真正未来库存）。 它把m_storagereservation表的Qty按采购和销售AS成了2个字段，QtyReserved，QtyOrdered。 最后得出数量三连：在手数量QtyOnhand，预留数量QtyReserved，在途数量QtyOrdered。 可是这拆出来的“QtyOrdered在途数量”和C_Order表的“QtyOrdered订购数量”字段名称重复了啊。 【毛病2开始了】 在[产品]-[库位]页签使用m_storage这个表来显示库位库存，但是产品窗口的isSOTrx='N'，结果： QtyReserved在PO词条显示为“在途数量”，QtyOrdered按正常显示为“订购数量”（或则说串到另外一个字段了），结果是：在手、在途、订购，可是系统是想显示数量三连啊：在手、预留、在途。 这翻译机制和系统默认都配合成啥了。不了解系统数据结构的人，这都是什么跟什么。 【解决办法】 理想结果：QtyReserved 场景词条，销售界面=预留，采购界面=在途 info window的数量三连正确显示：在手、预留、在途 m_storage的数量三连正确显示：在手、预留、在途 1. 不使用PO词条，容忍重名 QtyReserved=预留数量（采购界面有点不妥） QtyOrdered=订购数量（有点勉强） 其他什么都不用改。 这样，info window和m_storage页签的数量三连：在手、预留、订购。 结果有点勉强，主要是字段重名导致info窗口的字段必须是“订购”（与c_order.QtyOrdered一致） 2. 使用PO词条，不容忍重名 c_order.QtyOrdered :不改字段，翻译为“订购数量”（统一词条），不能是“销售数量”/“采购数量”（场景词条） m_storage.QtyOrdered：改字段，QtyInTransit/，翻译为“在途数量” 但是改了，还无法解决【毛病2】，毛病2方案有2个办法： 2.1 手动设置产品窗口isSOTrx='Y'，保证QtyReserved词条能显示“预留数量”，不显示PO词条“在途数量” 2.2 不改isSOTrx，将QtyReserved词条合成一个“预留数量”（但是采购界面有点不妥） 3. 凡是不妥的地方，都可以去掉field字段的集中维护选项。 这只能是实施时候完成，无法通过语言包直接一步到位，除非语言包带sql脚本。